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IIL REMARKS 

Claims 1-2, 5-16, 18-32, 34-43 and 45-50 are pending in this application. By this 
Amendment, claims 1, 5, 13, 27, 31 and 40 - 42 have been amended; and claims 3-4, 17, 33 and 
44 have been cancelled. The above amendments and following remarks are being made to 
facilitate early allowance of the presently claimed subject matter. Applicants do not acquiesce 
in the correctness of the rejections and reserve the right to present specific arguments regarding 
any rejected claims not specifically addressed. Further, Applicants reserve the right to pursue 
the full scope of the subject matter of the original claims in a subsequent patent application that 
claims priority to the instant application. Reconsideration in view of the above amendments and 
following remarks is respectfully requested. 

In the Office Action, claims 1-3, 6, 8, 10-16, 19, 21, 23-25, 27-32, 35-38, 40-43 and 46- 
49 were rejected under 35 U.S.C § 102(b) as anticipated by OraRep (Oracle 7 Sever Distributed 
Systems, Vol II: Replicated Data, Release 7.3, February, 1996, Oracle Corporation); and claims 
4-5, 17-18, 33-34, 39, 44-45 and 50 are rejected under 35 U.S.C § 103(a) as bring unpatentable 
over OraRep in view of Pal et al. (USPN 6,598,079). Withdrawal of these rejections in view of 
the above amendment is respectfully requested, for the reasons that follow: 

1. OraRep and Pa) et al.» either separately or in combination, do not disclose or 
suggest each and every claimed feature. 

First, the claimed invention recites, inter alia, that a "time duration of each repeating 
[update] step is shorter than a preceding repeating step[,]" as recited in claim 1 and claimed 
similarly in claims 13, 27, 31 and 40-42. As described by the specification of the current 
invention, an execution of a logged transaction on the target server occurs more quickly than the 
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execution of the same transaction on the source server since the target server is not interacting 
with users. Therefore, if an update is repeated, a time interval for each of the later updates will 
be shorter than a prior update. In addition, each update handles less transactions, which further 
shortens the time interval required. For example, if copying a database on the target server takes 
8 hours, the copy of the database on the target server is 8 hours behind the database on the 
source server because during the 8 hour copying there are transactions that occur on the source 
server. An update of the transactions that occurs in the 8 hours on the source server will takes 
less than 8 hours on the target server, e.g., 6 hours, because there is no interaction between the 
target server and users* After the update, which may take 6 hours, the database on the target 
server is 6 hours behind the database on the source server, and a second update is needed to 
make up this 6 hour lag. The time for the second update will be less than 6 hours for the same 
reason. Therefore, each later update will be for a reduced time interval than a prior update. The 
invention repeats this process until the lag period becomes acceptably short, and then transfers 
all users to the target server, i.e., it conducts a database migration. 

Applicants respectfully submit that OraRep and Pal et al., either separately or in 
combination, do not disclose or suggest, inter alia, a **time duration of each repeating [of the 
updating] step is shorter than a preceding repeating step.** OraRep disclose a method of 
replicating a database from a source server to a target server, which presents a number of 
fundamental differences compared to the claimed database migration. In particular, OraRep 
aims to have two databases mirror one another consistently despite being accessed by two 
different user groups. In contrast, during a database migration, the databases are close to 
identical or identical for only an instance time point prior to transforming users to the second 
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sever. In OraRep, the replication begins periodically at a fixed time and the time duration of 
each replication, although not mentioned in OraRep, is dependent on the size of the data to be 
replicated. That is, the time interval may increase or decrease depending on usage. As admitted 
by the Office, OraRep does not discuss time intervals relative to replications. 

Applicants submit that contrary to the Office's conclusion, Pal et at. also do not disclose 
or suggest time durations that are shorter for each updating step. Pal et al. disclose a system for 
allocating database objects from a larger database to clients for a limited time period, so that 
many users can access desired partitions of the larger database without preventing access to 
other partitions of the database by others. Abstract of Pal et al. In Pal et al., the time period of 
allocating database objects fluctuates to "ensure that a client cannot allocate a resource for so 
long as to affect other client's use of the resource.** Abstract of Pal et al In Pal et al., a time 
interval may increase, 4 Vhen a partition has a number of object records over a maximum 
number/* (col. 6, lines 16-17); or a time interval may also decrease, "when the number of object 
records for a partition goes below a minimum number[.]" Col. 6, lines 19-30. That is, in Pal et 
al*, the duration of an allocation depends on the number of objects for the partition to be 
allocated. Li Pal et aL, the time interval for an allocation may be longer or shorter than a prior 
allocation. By sharp contrast, in the current invention, a time duration of a later update is 
always shorter than that of a prior update. 

Pal et al. also do not disclose or suggest Updating." In contrast, Pal et ah only copy the 
object to the client once. See col. 5, lines 16-18. Once a client's allocation time is over, "the 
client may discard the object." Col. 5, line 41 . In view of the foregoing, Pal et al. do not 
disclose or suggest "a time duration of each repeating [of the updating] step is shorter than a 
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preceding repeating step[J" as recited in claim 1 and claimed similarly in claims 13, 27 > 31 and 
40-42 of the current invention. Accordingly, Applicants respectfully request withdrawal of the 
rejections. 

Second, the current invention recites, inter alia, Repeating the steps of logging at least 
one transaction and executing the at least one logged transaction on the second server prior to 
the step of queuing yntil a set point is met M" in claim I . This recitations is similarly repeated 
in claims 13, 27, 31 and 40-42. As noted above, in the current invention, a later update (i.e,, 
log/execute) always takes a shorter time interval than a prior update* As the updates repeat, the 
time intervals for the updates keep decreasing and the lag of the database on the second server 
compared to that on the first server keeps decreasing. Therefore, a user of the current invention 
can preset a set point for some feature of the updating at which updating stops and the 
identicalness of the database on the second server to the database on the first server satisfies a 
desired requirement so that transition to the second server can occur. See page 13, lines 1 1 -20 
of the application. (As used in the claims, the term "set point" includes all embodiments stated 
in the specification.) Neither OraRep or Pal et al, disclose or suggest this feature of the current 
invention. 

In particular, Pal et al. are not concerned with repeating updates because the objects are 
only copied once. In addition, Pal et al. are not concerned with the lag or the level of 
identicalness of the database on the second server (client) to the database on the first server. In 
view of the foregoing, Pal et al. do not disclose or suggest Repeating the steps of logging at 
least one transaction and executing the at least one logged transaction on the second server prior 
to the step of queuing until a set point is met[.J" In addition, OraRep is not concerned with 
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migrating a database, but replicates databases to ensure they mirror one another periodically 
despite being accessed by two different user groups. Accordingly, it is unlikely that a "set 
point" is implemented in OraRep. 

In view of the foregoing, Applicants respectfully request withdrawal of the rejections. 

2, There is no motivation or suggestion to combine OraRep and Pal et ah 

Applicants submit that there is no motivation or suggestion to combine OraRep and Pal 
et al. because the basic principles of OraRep and Pal et al. are different, and it is not feasible for 
OraRep to adopt the feature of Pal et al. regarding increasing or decreasing time intervals. As 
explained above, OraRep disclose a method of replicating a database from a source server to a 
target server. In particular, OraRep aims to have two databases mirror one another periodically 
despite being accessed by two different user groups. In contrast, during a migration, as claimed, 
the databases are close to identical or identical for only an instance time point prior to 
transferring users to the second sever. In OraRep, the replication occurs periodically and the 
time duration of each replication, although not mentioned in OraRep, is probably dependent on 
the size of the data to be replicated. That is, the time interval may increase or decrease 
depending on usage of the database to be replicated. As a result, OraRep cannot set a time 
interval for the replication, as the Pal et ah system does t because a preset time interval may be 
shorter than that required for the replication. 

In, addition, Applicants respectfully traverse the assertion of the Office that by combining 
Pal et al. and OraRep, 'the number of jobs queued would have been decreased steadily to an 
optimal level." Office Action at page 9. As stated above, Applicants submit that OraRep 
cannot achieve a decreased number of jobs by adopting Pal et al. In OraRep, a job queue must 
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be completed to complete the database replication. The job queue size, however, is unknown, 
and probably depends, for example, on the number of users accessing the source sever. 
Accordingly, the OraRep system cannot assign a time interval for replicating a database because 
it maybe less than the time required for the replication. In view of the forgoing. Applicants 
submit that the Office has failed to show a suggestion or motivation to combine, either in 
OraRep, or in Pal et al, or in the knowledge generally available to one of ordinary skill in the 
art Accordingly, Applicants request withdrawal of the rejection 

Claims 2 and 5-12 arc dependent on claim 1, claims 14-16 and 18-26 are dependent on 
claim 13, claims 28-30 are dependent on claim 27, claims 32 and 34-39 are dependent on claim 
31 and claim 44-50 are dependent on claim 42. The dependent claims are believed to be 
allowable based on the above arguments, as well as for their own additional features. 
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Applicants respectfully submit that the application is in condition for allowance. Should 
the Examiner believe that anything further is necessary to place the application in better 
condition for allowance, he is requested to contact Applicants' undersigned attorney at die 
telephone number listed below. 



Hoffman, Wamick & D'Alessandro LLC 
Three E-Comm Square 
Albany, New York 12207 
(518) 449-0044 
(518) 449-0047 (fax) 



Respectful ly submitted, 



Spencer K. Wamick 
Reg. No. 40,398 
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